feat(storage): Handle large read ranges in bidi read. #15152
feat(storage): Handle large read ranges in bidi read. #15152bajajneha27 merged 16 commits intogoogleapis:mainfrom
Conversation
product-auto-label
bot
added
the
api: storage
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #15152 +/- ##
==========================================
+ Coverage 92.97% 92.99% +0.02%
==========================================
Files 2402 2403 +1
Lines 218287 218506 +219
==========================================
+ Hits 202961 203210 +249
+ Misses 15326 15296 -30 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
devbww
left a comment
devbww
left a comment
There was a problem hiding this comment.
Reviewable status: 0 of 15 files reviewed, 6 unresolved discussions (waiting on @bajajneha27, @ddelgrosso1, and @scotthart)
google/cloud/storage/internal/async/object_descriptor_impl.cc line 251 at r4 (raw file):
Previously, scotthart (Scott Hart) wrote…
If you can guarantee that no other thread would ever be executing any of the code sections that modify
streams_at the same time that the current thread readsstreams_here, then you are ok without the lock.
And the only way to guarantee that is to show that another lock serializes these actions (in which case this lock isn't needed), or to show the actions are all run by the same thread (in which case this lock also isn't needed). Both of these require meta information, so the reliable way to make the guarantee locally is with a lock that protects both reads and writes.
bajajneha27
dismissed stale reviews from rajeevpodar and ddelgrosso1
via
7c157f4
bajajneha27
left a comment
bajajneha27
left a comment
There was a problem hiding this comment.
Reviewable status: 0 of 15 files reviewed, 6 unresolved discussions (waiting on @ddelgrosso1, @devbww, @rajeevpodar, and @scotthart)
google/cloud/storage/internal/async/object_descriptor_impl.cc line 251 at r4 (raw file):
Previously, devbww (Bradley White) wrote…
And the only way to guarantee that is to show that another lock serializes these actions (in which case this lock isn't needed), or to show the actions are all run by the same thread (in which case this lock also isn't needed). Both of these require meta information, so the reliable way to make the guarantee locally is with a lock that protects both reads and writes.
Done.
|
I'm not sure why other jobs are not kicking in. There's nothing in the logs. |
scotthart
left a comment
scotthart
left a comment
There was a problem hiding this comment.
Reviewed 3 of 7 files at r1, 4 of 7 files at r2, 7 of 8 files at r4, 1 of 1 files at r5, all commit messages.
Reviewable status: all files reviewed, 6 unresolved discussions (waiting on @bajajneha27, @ddelgrosso1, @devbww, and @rajeevpodar)
|
/gcbrun |
5 participants
Part of #15340
This change is